Amazon VPC Latticeが一般利用可能になりました

Amazon VPC Latticeが一般利用可能になりました

一般利用可能になったVPC Latticeを試してみた様子をご紹介します
Clock Icon2023.04.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ども、大瀧です。 昨年re:Invent 2022での発表後Private PreviewだったVPC Latticeが一般利用可能(GA: General Availability)になり、全てのアカウントで利用できるようになりました。

VPC Latticeとは

VPC Lattice(日本語では"格子")はVPC向けのリバースプロキシサービスで、現時点ではHTTPとHTTPSをサポートします。リバースプロキシサービスというとELBがありますが、ELBがインターネット向けの様々な機能を持つのに対してVPC LatticeはVPC向けのシンプルな機能に絞りつつ、異なるVPC向けにELBではVPCエンドポイントやVPCピア接続を追加構成するのに対して、VPC LatticeはVPCをまたぐ仕組みを内包しているのが特徴です。あともう一つ、ELBではHTTPS通信のために必要だったTLS証明書がVPC LatticeではデフォルトのDNS名に対応するワイルドカード証明書が用意されます(カスタムドメインおよびTLS証明書も利用できます)。

設定手順

では試してみましょう。今回は最小構成としてターゲットとするALBとリクエストを送るEC2インスタンスをあらかじめ用意し、VPC Lattice経由でアクセスしてみます。

  • リージョン: 東京リージョン
  • ELB: ALB、80番ポートを固定レスポンス200"ok"で設定

1. VPC LatticeサービスネットワークとVPC Latticeサービスの作成

VPC LatticeはAWS管理コンソールのVPC管理画面で設定します。VPC管理画面のメニューにある「VPC格子」配下にあります。

まずは、[Getting Started] - [サービスネットワークを作成する]をクリックしウィザードを表示します。

サービスネットワークを作成画面では、任意のサービスネットワーク名を入力し、画面を下にスクロールします。

続いてVPC LatticeサービスとVPCの関連付けを進めます。VPC Latticeサービスはここで新規作成しましょう。[Amazon VPC Latticeサービスを作成]リンクをクリックして作成画面を開きます。

VPC Latticeサービスの作成画面では、任意のサービス名を入力します。

続いてカスタムドメインやサービスアクセスの認証タイプを選択します。今回は特に変更せずにスクロールし[次へ]をクリックします。

ルーティングを定義画面、ネットワークの関連付けを作成画面は別の手順で行う作業のため、どちらもそのまま[次へ]で進み、[VPC Latticeサービスを作成]をクリックしサービス作成を実行します。

サービスの作成が完了したら、サービスネットワークの作成画面に戻り、先ほどのサービスの関連付けの右の再読み込みボタンをクリック、表示されるサービスを選択します。

VPCの関連付けでは、[VPCの関連付けを追加]をクリックします。

今回はEC2インスタンスを配置しているVPCを選択し、セキュリティグループはリスナに応じて80番ないし443番を許可するセキュリティグループを選択します。

[サービスネットワークの作成]をクリックして実行します。

2. VPC Latticeターゲットグループとリスナーの追加

続いてトラフィックを受け取るためのリスナーおよびプロキシ先のターゲットグループを追加します(この辺りの設定項目はALBとほぼ同様です)。メニューから[VPC格子 ターゲットグループ] - [ターゲットグループを作成]をクリックします。

ターゲットグループ作成画面では、ターゲットタイプの選択から[Application Load Balancer]を選択、任意のターゲットグループ名を入力し、プロトコル:ポートはプロキシ先の構成済みALBのリスナーに合わせます(今回はHTTP80番ポートのリスナーを設定しているのでそれに合わせます)

ターゲットの登録画面では構成済みのALBを選択し、ターゲットグループを作成します。

続いてリスナーを追加します。メニューから[VPC格子 サービス]を選択、リストから先ほど作成したVPC Latticeサービスを選択し[ルーティング]タブの右側に表示される[リスナーの追加]ボタンをクリックします。

[プロトコル:ポート]は「HTTP」を選択して「80」と入力、デフォルトアクションは作ほど作成したターゲットグループを選択し、リスナーを作成します。

これでOKです。

動作確認

それではEC2インスタンスからVPC Lattice経由でALBにアクセスしてみます。エンドポイントはVPC Latticeサービスのプロパティにある[ドメイン名]で確認できます。

$ curl -v http://latticeservice01-XXXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws
*   Trying 169.254.171.32:80...
* Connected to latticeservice01-XXXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws (169.254.171.32) port 80 (#0)
> GET / HTTP/1.1
> Host: latticeservice01-XXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 200 OK
< server: awselb/2.0
< date: Sat, 01 Apr 2023 04:23:32 GMT
< content-type: text/plain; charset=utf-8
< content-length: 2
<
* Connection #0 to host latticeservice01-XXXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws left intact
ok%

レスポンスが返ってきました!ちなみにHTTPS:443のリスナーを追加すると、以下のようにデフォルトのTLS証明書でHTTPS通信できます。

$ curl -v https://latticeservice01-XXXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws
*   Trying 169.254.171.32:443...
* Connected to latticeservice01-XXXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws (169.254.171.32) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws
*  start date: Mar 24 00:00:00 2023 GMT
*  expire date: Apr 22 23:59:59 2024 GMT
*  subjectAltName: host "latticeservice01-XXXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws" matched cert's "*.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws"
*  issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
*  SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: latticeservice01-XXXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0xaaaae3a507a0)
> GET / HTTP/2
> Host: latticeservice01-XXXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws
> user-agent: curl/7.88.1
> accept: */*
>
< HTTP/2 200
< server: awselb/2.0
< date: Sat, 01 Apr 2023 04:35:18 GMT
< content-type: text/plain; charset=utf-8
< content-length: 2
<
* Connection #0 to host latticeservice01-XXXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws left intact
ok$

AmazonがイシュアのTLS証明書が自動でセットされ、利用できていることがわかりますね。

蛇足: VPC Latticeのネットワーク構成

DNS名前解決の様子を見てみると、VPC LatticeのエンドポイントのIPアドレスはリンクローカルアドレスであることに気づきました。同じVPC向けの機能であるPrivateLinkがENIを作成する一方でVPC LatticeはENIなしでVPCのコンポーネントの一部として組み込まれていて、VPCのCIDR(プライベートIPアドレス帯域)やアベイラビリティゾーンに依存しない構成になっているのがわかります。手元のMacbookからDNS名を問い合わせてみると...

% host latticeservice01-XXXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws
latticeservice01-XXXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws has address 169.254.171.0
latticeservice01-XXXXXXXXXXXX.XXXXXXXX.vpc-lattice-svcs.ap-northeast-1.on.aws has IPv6 address fd00:ec2:80::a9fe:ab60
%

IPv4、IPv6ともに名前解決できました。ELBやRDSのプライベート構成と同様、インターネットから名前解決できるけどプライベートIPアドレスなので外部からはアクセスできないタイプのリソースですね。インターネットから解決できるということは、VPCごとに配置されるAmazon DNSに依らず全てのAWSアカウントのVPCで一意ということが推測できます。

まとめ

一般利用可能になったVPC Latticeを試してみた様子をご紹介しました。VPC Latticeは非常に多機能なので、興味を持った方はいろいろ試してみることをお奨めします。

参考URL

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.